Wer sorgt dafür, dass die CI/CD-Pipeline nicht nur funktioniert, sondern jeden Tag zuverlässig läuft? Wer definiert Security-Standards – und setzt sie durch? Wer zieht die Konsequenzen, wenn sich ein Domänenmodell als falsch erweist? Wer verantwortet Testbarkeit und denkt Observability von Anfang an mit?

Diese Fragen tauchen auf und landen irgendwo. Bei Architekt:innen, bei engagierten Entwickler:innen – oder bei niemandem, bis es zu spät ist. Es gibt dann Entwicklerinnen und Entwickler, die genau diese Lücke besetzen. Sie sind nah genug am Code, um die Folgen von Entscheidungen zu spüren – und denken weit genug, um das System als Ganzes im Blick zu behalten. Sie kodieren und koordinieren.

Diese Rolle bildet sich in fast jeder Organisation heraus, hat aber keinen offiziellen Namen. Ohne sie bleiben viele Themen liegen – bis sie zum Problem werden.

Die bekannte Aufteilung greift zu kurz

Lars Röwekamp kennt diese Sphäre aus der Praxis. Als CTO von OpenKnowledge hat er viele große Entwicklungs-Organisationen von innen gesehen und als Program Chair leitet er den MAD-Summit bereits seit über zehn Jahren. Im Gespräch beschreibt er ein Muster, das in vielen Unternehmen ähnlich aussieht: Es gibt Leute, die sich spontan um die schwierigen Dinge kümmern – ohne offizielles Mandat, ohne offiziellen Jobtitel dafür.

Diese Menschen befinden sich üblicherweise zwischen den Stühlen. Nicht im Elfenbeinturm der Architektur – aber auch nicht voll im Code. Sie verbinden beides und übernehmen oft Verantwortung, die formal niemandem gehört. 

Wir haben versucht, diese Rolle greifbar zu machen, indem wir wiederkehrende Muster in ihrer Arbeit und ihren Entscheidungen herausgearbeitet haben. Entstanden ist eine Liste von dreizehn Werten, die diese Haltung beschreiben.

Dreizehn Werte – und das Bild einer Rolle, die so nie benannt wurde

1. Verantwortung für den kompletten Software Life Cycle

Verantwortung endet nicht am eigenen Code. Sie umfasst das System als Ganzes – von der ersten Entscheidung bis zum Betrieb. Lars Röwekamp formuliert es so: „Du fühlst dich für den kompletten Software Lifecycle verantwortlich.“ Dazu gehören auch die Non-functional Requirements. Fragen nach Performance, Security oder einem zufällig fehlenden Security-Zertifikat tauchen oft erst spät auf. Dann ist da jemand, der nicht lange diskutiert, sondern sagt: Ich kümmere mich darum – und es klärt.

2. System Thinking statt Feature Thinking

In der Entwicklung dreht sich vieles um Tickets. Das ist notwendig – und engt den Blick. „Ein Feature lebt nicht losgelöst – es gehört zu einem System“, sagt Lars Röwekamp. Im Daily sieht jedes Ticket gleich aus. Erst später zeigt sich, dass eine kleine Änderung eine Kette von Nebenwirkungen auslöst. Genau dieser Unterschied geht im Alltag schnell verloren.

3. Stabilität vor Experimentierfreude

Im produktiven System wird nicht experimentiert. Ausprobieren und Einsatz sind getrennt. Neue Technologien kommen erst dann ins System, wenn klar ist, wie sie sich verhalten – und wie sie im Betrieb gehandhabt werden können. Das neue Framework gehört ins Nebenprojekt, nicht in den kritischen Service.

Systeme modernisieren statt nur migrieren

Power-Workshops zu Modernisierung & Service-Architektur (22. - 26. Juni 2026, München)

Jetzt entdecken!

4. Architektur als Mittel zur Komplexitätsbeherrschung

Architektur entsteht aus Anforderungen – und aus der Unsicherheit, wie sich ein System verändern wird. Lars Röwekamp: so viel wie nötig, so wenig wie möglich. In der Praxis sieht man oft das Gegenteil: zusätzliche Schichten, neue Services, mehr Abhängigkeiten – ohne dass ein konkretes Problem dahintersteht oder sich ein echter Vorteil abzeichnet.

5. Evolvierbarkeit statt Disruption

In manchen Systemen wird jede Änderung zum Eingriff ins Ganze. Wer helfen will, das zu vermeiden, trifft Entscheidungen so, dass Anpassungen möglich bleiben. Lars Röwekamp: „Mein System muss so aufgebaut sein, dass ich heute schneller als gestern die Dinge an den Start bringen kann.“ Strukturen werden so angelegt, dass Änderungen lokal bleiben – und sich nicht durchs ganze System ziehen.

6. Klare fachliche Grenzen (Domänenfokus)

In vielen Teams verschiebt sich der Fokus auf Infrastruktur und Tools. Diskussionen drehen sich ausschließlich um Deployments, Pipelines oder Frameworks. Die eigentliche Fachlichkeit rutscht nach hinten. Irgendwann passt das System technisch – aber nicht mehr zum Geschäftsziel.

7. Testbarkeit als Grundvoraussetzung

Hohe Testabdeckung sieht gut aus, sagt aber wenig. Die Pipeline ist grün, alle Checks laufen durch – und trotzdem stimmt das Ergebnis fachlich nicht. Getestet wurde der Code, nicht das Verhalten.

8. Langfristige Wartbarkeit als Qualitätsmaßstab

Ob ein System wartbar ist, zeigt sich erst, wenn jemand anderes es ändern muss. Dann wird sichtbar, ob es noch verstanden wird. Es wird nicht für den eigenen Moment gebaut, sondern für die nächste Person, die damit arbeiten muss. Entscheidungen orientieren sich daran, ob das System verständlich und veränderbar bleibt.

9. Dokumentation als Teil der Architektur

In vielen Teams werden Entscheidungen nach einiger Zeit erneut in Frage gestellt, weil niemand mehr weiß, warum sie überhaupt getroffen wurden. Lars Röwekamp beschreibt das so: „Ein, zwei Jahre später wird über Dinge diskutiert, die vorher völlig klar waren – und keiner weiß mehr, warum wir so entschieden haben.“ Die Diskussion beginnt von vorn.

10. Platform Engineering als Haltung

Plattformen geben Regeln vor – für Infrastruktur, Deployment und Betrieb. Diese Regeln lassen sich einhalten oder umgehen. Der schnellste Weg ist oft der eigene: Ein Script hier, ein spezieller Hack dort. Kurzfristig funktioniert das. Langfristig steht man allein damit und schadet sogar dem System.

11. Security als Grundprinzip

Security entsteht nicht dadurch, dass jeder sie selbst baut. In größeren Systemen gibt es dafür spezialisierte Lösungen, Frameworks und Teams. Trotzdem entsteht immer wieder die gleiche Situation: Es geht schneller, es mal eben selbst zu lösen. Genau dort beginnen die Probleme und deswegen orientiert man sich am Grundprinzip.

12. Observability und Transparenz

Im Betrieb zeigt sich, was ein System tatsächlich tut. Ein Fehler tritt auf, aber niemand kann sagen, warum. Logs fehlen, Metriken sind unvollständig. Die Suche beginnt im Dunkeln.

13. Verantwortungsbewusster und wirtschaftlicher Einsatz von AI

AI ist kein Standardbaustein. Lars Röwekamp meint: „Selbst wenn ihr es heute noch nicht nutzen könnt – ihr müsst euch jetzt damit beschäftigen.“ In der Praxis zeigt sich schnell, dass viele Probleme ohne AI besser gelöst sind – vor allem dort, wo Abläufe klar definiert sind. Die eigentliche Aufgabe liegt darin, zu entscheiden, wo sie eingesetzt wird – und wo nicht.

Mit AI wird sichtbar, worauf es schon immer ankam

AI verändert die Systeme – die Grundfrage bleibt dieselbe: Wer beherrscht das System? Viele behandeln AI vor allem als Technologie-Frage und diskutieren Modelle, Tools und APIs. Das ist naheliegend, weil sich genau dort gerade so viel bewegt. In den Gesprächen mit Teilnehmern und Kunden zeigt sich jedoch ein anderes Bild, meint Lars. „Mittlerweile ist nahezu allen klar, dass sie das Thema AI im Umfeld des Software Engineerings nicht aussitzen werden können. Die Verunsicherung, wie man das Thema angehen soll, ist extrem groß“.

In der Praxis zeigt sich etwas anderes: je sorgfältiger du bist in deinem Engineering, desto bessere Voraussetzungen schaffst du, AI produktiv und ohne Risiko zu integrieren. 

Genau hier zeigt sich die Rolle, die wir mit unserer Liste zu fassen versuchen. Wer in Systemen denkt, erkennt, wo AI sinnvoll eingesetzt werden kann. Wer Verantwortung übernimmt, sorgt dafür, dass ihre Ergebnisse überprüfbar bleiben. Und wer Architektur versteht, kann ihre Wirkung begrenzen, statt ihr ausgeliefert zu sein. AI verändert die Arbeit – aber sie verschiebt nicht die Grundsätze, auf dem tragfähige Systeme entstehen.

Praxis war immer der Maßstab

Wer die über 10-jährige Geschichte des MAD Summit kennt, erkennt unsere Liste wieder. Die Themen haben sich verändert – vom Java Enterprise Summit über Microservices und APIs bis zu Domain Driven Design und dem heutigen “MAD – Make, Adapt, Deliver”. Der Name hat sich angepasst, der Anspruch nicht. Lars Röwekamp formuliert ihn so: „Es ging uns beim MAD Summit und seinen Vorgängern schon immer um die Beherrschung großer, komplexer und in der Regel verteilter Enterprise-Systeme.“

Über die Jahre wurde deutlicher, was dafür nötig ist. Technologie allein ist es nicht. Architektur, Organisation und Fachlichkeit greifen ineinander. Praxis war dabei immer der Maßstab. Der MAD Summit setzt konsequent auf Arbeit an echten Problemen. 

Gleichzeitig zeigt sich eine Grenze dieses Formats. „Schwierig wird es immer dann, wenn wir mehrere Themen im Zusammenspiel zeigen und damit noch näher an die Praxis rücken wollen. Da ist ein halber Tag einfach deutlich zu wenig“, sagt Lars Röwekamp.

Beim MAD Summit 2026 im kommenden Juni verschiebt sich deshalb der Schwerpunkt: Bootcamps stehen im Zentrum: zweitägige Workshops, in denen an Systemen ausführlich gearbeitet wird. Die Themen folgen derselben Logik wie die Werte. Es geht nicht darum, was ein Modell kann, sondern wie es in bestehende Systeme eingebunden wird. Beispiele: 

GenAI im Enterprise integrieren – das Modell ist nicht das Problem. Das Problem ist das System, in das es eingebaut wird. Dieses Bootcamp arbeitet mit bestehenden Architekturen, realen Integrationspunkten und den Entscheidungen, die nicht trivial sind.

Architecting for Agentic AI – autonome Systeme handeln. Sie treffen Entscheidungen, die früher Menschen getroffen haben. Das stellt andere Anforderungen an Architektur als klassische Komponenten. Wer die Grenzen nicht bewusst zieht, findet bald die Kontrolle.

Event Storming – wer seine Domäne nicht kennt, kann AI nicht sinnvoll einsetzen. Das ist keine Vorbedingung für gestern. Es ist die Vorbedingung für alles, was danach kommt.

Der richtige Ort für diese Diskussion ist die Praxis

Diese Liste unserer “Enterprise-Werte” ist ein Ansatz und erhebt keinen Anspruch auf Vollständigkeit. Wir glauben aber, dass es insbesondere im Lichte von AI wichtig ist, der beschriebenen Rolle die sich in den meisten Organisationen eher ad-hoc bildet als geplant, zu mehr Reputation zu verhelfen. Wir würden mit unseren Überlegungen – und womöglich deinen Ergänzungen – gerne dazu beitragen.

AI stellt Systeme, Organisationen und Engineers für eine Fülle neuer Herausforderungen – die sich allerdings durch die Besinnung auf so klassische Werte, wie wir sie hier auflisten, erfolgreich bewältigen lassen.

AI bedeutet keinesfalls, dass Engineering eines Tages obsolet wird, sondern im Gegenteil: dass wir mehr Engineering benötigen denn je.

Auf dem MAD-Summit wollen wir mit Euch dieses Wissen vertiefen und gemeinsam aufbrechen ins AI-Zeitalter – no hype, but real value.